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Status of this Memo 


This memo defines an Experimental Protocol for the Internet 
community. It does not specify an Internet standard of any kind. 
Discussion and suggestions for improvement are requested. 
Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (1999). All Rights Reserved. 
Abstract 
This memo describes a syntax for securing messages sent using the 
Hypertext Transfer Protocol (HTTP), which forms the basis for the 
World Wide Web. Secure HTTP (S-HTTP) provides independently 


applicable security services for transaction confidentiality, 
authenticity/integrity and non-repudiability of origin. 


The protocol emphasizes maximum flexibility in choice of key 
management mechanisms, security policies and cryptographic algorithms 
by supporting option negotiation between parties for each 
transaction. 
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Introduction 


The World Wide Web (WWW) is a distributed hypermedia system which has 
gained widespread acceptance among Internet users. Although WWW 
browsers support other, preexisting Internet application protocols, 
the native and primary protocol used between WWW clients and servers 
is the HyperText Transfer Protocol (HTTP) [RFC-2616]. The ease of 
use of the Web has prompted its widespread employment as a 
client/server architecture for many applications. Many such 
applications require the client and server to be able to authenticate 
each other and exchange sensitive information confidentially. The 
original HTTP specification had only modest support for the 
cryptographic mechanisms appropriate for such transactions. 


Secure HTTP (S-HTTP) provides secure communication mechanisms between 
an HTTP client-server pair in order to enable spontaneous commercial 
transactions for a wide range of applications. Our design intent is 
to provide a flexible protocol that supports multiple orthogonal 
operation modes, key management mechanisms, trust models, 
cryptographic algorithms and encapsulation formats through option 
negotiation between parties for each transaction. 


1. Summary of Features 


Secure HTTP is a secure message-oriented communications protocol 
designed for use in conjunction with HTTP. It is designed to coexist 
with HTTP’s messaging model and to be easily integrated with HTTP 
applications. 


Secure HTTP provides a variety of security mechanisms to HTTP clients 
and servers, providing the security service options appropriate to 
the wide range of potential end uses possible for the World-Wide Web. 
The protocol provides symmetric capabilities to both client and 
server (in that equal treatment is given to both requests and 
replies, as well as for the preferences of both parties) while 
preserving the transaction model and implementation characteristics 
of HTTP. 


Several cryptographic message format standards may be incorporated 
into S-HTTP clients and servers, particularly, but in principle not 
limited to, [CMS] and [MOSS]. S-HTTP supports interoperation among a 
variety of implementations, and is compatible with HTTP.  S-HTTP 
aware clients can communicate with S-HTTP oblivious servers and 
vice-versa, although such transactions obviously would not use S-HTTP 
security features. 


S-HTTP does not require client-side public key certificates (or 
public keys), as it supports symmetric key-only operation modes. 
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This is significant because it means that spontaneous private 
transactions can occur without requiring individual users to have 
an established public key. While S-HTTP is able to take advantage 
of ubiquitous certification infrastructures, its deployment does 
not require it. 


S-HTTP supports end-to-end secure transactions, in contrast with the 
original HTTP authorization mechanisms which require the client to 
attempt access and be denied before the security mechanism is 
employed. Clients may be "primed" to initiate a secure transaction 
(typically using information supplied in message headers); this may 
be used to support encryption of fill-out forms, for example. With 
S-HTTP, no sensitive data need ever be sent over the network in the 
clear. 


S-HTTP provides full flexibility of cryptographic algorithms, modes 
and parameters. Option negotiation is used to allow clients and 
servers to agree on transaction modes (e.g., should the request be 


signed or encrypted or both -- similarly for the reply?); 
cryptographic algorithms (RSA vs. DSA for signing, DES vs. 
RC2 for encrypting, etc.); and certificate selection 


(please sign with your "Block-buster Video certificate"). 


S-HTTP attempts to avoid presuming a particular trust model, although 
its designers admit to a conscious effort to facilitate 
multiply-rooted hierarchical trust, and anticipate that principals may 
have many public key certificates. 


S-HTTP differs from Digest-Authentication, described in [RFC-2617] in 
that it provides support for public key cryptography and consequently 
digital signature capability, as well as providing confidentiality. 


1.2. Changes 


This document describes S-HTTP/1.4. It differs from the previous 

memo in that it differs from the previous memo in its support of 

the Cryptographic Message Syntax (CMS) [CMS], a successor to PKCS-7; 
and hence now supports the Diffie-Hellman and the (NIST) Digital 
Signature Standard cryptosystems. CMS used in RSA mode is bits on the 
wire compatible with PKCS-7. 
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1.3. Processing Model 
1.3.1. Message Preparation 


The creation of an S-HTTP message Can be thought of as a a function 
with three inputs: 


1. The cleartext message. This is either an HTTP message 

or some other data object. Note that since the cleartext message 
is carried transparently, headers and all, any version of HTTP 
can be carried within an S-HTTP wrapper. 

2. The receiver’s cryptographic preferences and keying material. 
This is either explicitly specified by the receiver or subject 
to some default set of preferences. 

3. The sender’s cryptographic preferences and keying material. 
This input to the function can be thought of as implicit 

since it exists only in the memory of the sender. 


In order to create an S-HTTP message, then, the sender integrates the 
sender’s preferences with the receiver’s preferences. The result of 
this is a list of cryptographic enhancements to be applied and keying 
material to be used to apply them. This may require some user 
intervention. For instance, there might be multiple keys available to 
sign the message. (See Section 3.2.4.9.3 for more on this topic.) 
Using this data, the sender applies the enhancements to the message 
clear-text to create the S-HTTP message. 


The processing steps required to transform the cleartext message into 
the S-HTTP message are described in Sections 2 and 3. The processing 
steps required to merge the sender's and receiver's preferences are 
described in Sections 3.2. 


1.3.2. Message Recovery 


The recovery of an S-HTTP message Can be thought of as a function of 
four distinct inputs: 


1. The S-HTTP message. 

2. The receiver's stated cryptographic preferences and keying 
material. The receiver has the opportunity to remember what 
cryptographic preferences it provided in order for this 
document to be dereferenced. 

3. The receiver’s current cryptographic preferences and 
keying material. 

4. The sender's previously stated cryptographic options. 
The sender may have stated that he would perform certain 
cryptographic operations in this message. (Again, see 
sections 4 and 5 for details on how to do this.) 
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In order to recover an S-HTTP message, the receiver needs to read the 
headers to discover which cryptographic transformations were 
performed on the message, then remove the transformations using some 
combination of the sender’s and receiver’s keying material, while 
taking note of which enhancements were applied. 


The receiver may also choose to verify that the applied enhancements 
match both the enhancements that the sender said he would apply 
(input 4 above) and that the receiver requested (input 2 above) as 
well as the current preferences to see if the S-HTTP message was 
appropriately transformed. This process may require interaction with 
the user to verify that the enhancements are acceptable to the user. 
(See Section 6.4 for more on this topic.) 


1.4. Modes of Operation 


Message protection may be provided on three orthogonal axes: 
signature, authentication, and encryption. Any message may be signed, 
authenticated, encrypted, or any combination of these (including no 
protection). 


Multiple key management mechanisms are supported, including 
password-style manually shared secrets and public-key key exchange. 
In particular, provision has been made for prearranged (in an earlier 
transaction or out of band) symmetric session keys in order to send 
confidential messages to those who have no public key pair. 


Additionally, a challenge-response ("nonce") mechanism is provided to 
allow parties to assure themselves of transaction freshness. 


1.4.1. Signature 


If the digital signature enhancement is applied, an appropriate 
certificate may either be attached to the message (possibly along 
with a certificate chain) or the sender may expect the recipient to 
obtain the required certificate (chain) independently. 


1.4.2. Key Exchange and Encryption 
In support of bulk encryption, S-HTTP defines two key transfer 
mechanisms, one using public-key enveloped key exchange and another 


with externally arranged keys. 


In the former case, the symmetric-key cryptosystem parameter is 
passed encrypted under the receiver's public key. 
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In the latter mode, we encrypt the content using a prearranged 
session key, with key identification information specified on one of 
the header lines. 


1.4.3. Message Integrity and Sender Authentication 


Secure HTTP provides a means to verify message integrity and sender 
authenticity for a message via the computation of a Message 
Authentication Code (MAC), computed as a keyed hash over the document 
using a shared secret -- which could potentially have been arranged 
in a number of ways, e.g.: manual arrangement or 'inband” key 
management. This technique requires neither the use of public key 
cryptography nor encryption. 


This mechanism is also useful for cases where it is appropriate to 
allow parties to identify each other reliably in a transaction 
without providing (third-party) non-repudiability for the 
transactions themselves. The provision of this mechanism is motivated 
by our bias that the action of "Signing" a transaction should be 
explicit and conscious for the user, whereas many authentication 
needs (i.e., access control) can be met with a lighter-weight 
mechanism that retains the scalability advantages of public-key 
cryptography for key exchange. 


1.4.4. Freshness 


The protocol provides a simple challenge-response mechanism, allowing 
both parties to insure the freshness of transmissions. Additionally, 
the integrity protection provided to HTTP headers permits 
implementations to consider the Date: header allowable in HTTP 
messages as a freshness indicator, where appropriate (although this 
requires implementations to make allowances for maximum clock skew 
between parties, which we choose not to specify). 


1.5. Implementation Options 


In order to encourage widespread adoption of secure documents for the 
World-Wide Web in the face of the broad scope of application 
requirements, variability of user sophistication, and disparate 
implementation constraints, Secure HTTP deliberately caters to a 
variety of implementation options. See Section 8 for implementation 
recommendations and requirements. 


2. Message Format 
Syntactically, Secure HTTP messages are the same as HTTP, consisting 


of a request or status line followed by headers and a body. However, 
the range of headers is different and the bodies are typically 
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2 


2 


2 


cryptographically enhanced. 


-l. Notational Conventions 


This document uses the augmented BNF from HTTP [RFC-2616]. You should 
refer to that document for a description of the syntax. 


.2. Request Line 


In order to differentiate S-HTTP messages from HTTP messages and 
allow for special processing, the request line should use the special 
Secure" method and use the protocol designator "Secure-HTTP/1.4". 
Consequently, Secure-HTTP and HTTP processing can be intermixed on 
the same TCP port, e.g. port 80. In order to prevent leakage of 
potentially sensitive information Request-URI should be "*". For 
example: 


Secure * Secure-HTTP/1.4 


When communicating via a proxy, the Request-URI should be consist of 
the AbsoluteURI. Typically, the rel path section should be replaced 
by "*" to minimize the information passed to in the clear. (e.g. 
http://www.terisa.com/*); proxies should remove the appropriate 
amount of this information to minimize the threat of traffic 
analysis. See Section 7.2.2.1 for a situation where providing more 
information is appropriate. 


3. The Status Line 


S-HTTP responses should use the protocol designator "Secure- 
HTTP/1.4". For example: 


Secure-HTTP/1.4 200 OK 


Note that the status in the Secure HTTP response line does not 
indicate anything about the success or failure of the unwrapped HTTP 
request. Servers should always use 200 OK provided that the Secure 
HTTP processing is successful. This prevents analysis of success or 
failure for any request, which the correct recipient can determine 
from the encapsulated data. All case variations should be accepted. 


4. Secure HTTP Header Lines 


The header lines described in this section go in the header of a 
Secure HTTP message. All except 'Content-Type” and 'Content-Privacy- 
Domain’ are optional. The message body shall be separated from the 
header block by two successive CRLFs. 
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All data and fields in header lines should be treated as case 
insensitive unless otherwise specified. Linear whitespace [RFC-822] 
should be used only as a token separator unless otherwise quoted. 
Long header lines may be line folded in the style of [RFC-822]. 


This document refers to the header block following the S-HTTP 
request/response line and preceding the successive CRLFs collectively 
as "S-HTTP headers". 


2.4.1. Content-Privacy-Domain 
The two values defined by this document are 'MOSS” and ’CMS’. CMS 
refers to the privacy enhancement specified in section 2.6.1. MOSS 
refers to the format defined in [RFC-1847] and [RFC-1848]. 

2.4.2. Content-Type for CMS 
Under normal conditions, the terminal encapsulated content (after all 
privacy enhancements have been removed) would be an HTTP message. In 
this case, there shall be a Content-Type line reading: 

Content-Type: message/http 

The message/http content type is defined in RFC-2616. 
If the inner message is an S-HTTP message, then the content type 


shall be '"application/s-http'. (See Appendix for the definition of 
this.) 


It is intended that these types be registered with IANA as MIME 
content types. 


The terminal content may be of some other type provided that the type 
is properly indicated by the use of an appropriate Content-Type 
header line. In this case, the header fields for the encapsulation of 
the terminal content apply to the terminal content (the 'final 
headers’). But in any case, final headers should themselves always be 
S-HTTP encapsulated, so that the applicable S-HTTP/HTTP headers are 
never passed unenhanced. 


S-HTTP encapsulation of non-HTTP data is a useful mechanism for 
passing pre-enhanced data (especially presigned data) without 
requiring that the HTTP headers themselves be pre-enhanced. 
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2.4.3. Content-Type for MOSS 


The Content-Type for MOSS shall be an acceptable MIME content type 
describing the cryptographic processing applied. (e.g. 
multipart/signed). The content type of the inner content is described 
in the content type line corresponding to that inner content, and for 
HTTP messages shall be ’message/http’. 


2.4.4. Prearranged-Key-Info 


This header line is intended to convey information about a key which 
has been arranged outside of the internal cryptographic format. One 
use of this is to permit in-band communication of session keys for 
return encryption in the case where one of the parties does not have 
a key pair. However, this should also be useful in the event that the 
parties choose to use some other mechanism, for instance, a one-time 
key list. 


This specification defines two methods for exchanging named keys, 
Inband, Outband. Inband indicates that the session key was exchanged 
previously, using a Key-Assign header of the corresponding method. 
Outband arrangements imply that agents have external access to key 
materials corresponding to a given name, presumably via database 
access or perhaps supplied immediately by a user from keyboard input. 
The syntax for the header line is: 


Prearranged-Key-Info = 


"Prearranged-Key-Info" ":" Hdr-Cipher "," CoveredDEK "," CoverKey-ID 
CoverKey-ID = method ":" key-name 
CoveredDEK = *HEX 
method = "inband" |  "outband" 


While chaining ciphers require an Initialization Vector (IV) [FIPS- 
81] to start off the chaining, that information is not carried by 
this field. Rather, it should be passed internal to the cryptographic 
format being used. Likewise, the bulk cipher used is specified in 
this fashion. 


<Hdr-Cipher> should be the name of the block cipher used to encrypt 
the session key (see section 3.2.4.7) 


<CoveredDEK> is the protected Data Encryption Key (a.k.a. transaction 
key) under which the encapsulated message was encrypted. It should be 
appropriately (randomly) generated by the sending agent, then 
encrypted under the cover of the negotiated key (a.k.a. session key) 
using the indicated header cipher, and then converted into hex. 


Rescorla € Schiffman Experimental [Page 10] 


RFC 2660 The Secure HyperText Transfer Protocol August 1999 


In order to avoid name collisions, cover key namespaces must be 
maintained separately by host and port. 


Note that some Content-Privacy-Domains, notably likely future 
revisions of MOSS and CMS may have support for symmetric key 
management. 


The Prearranged-Key-Info field need not be used in such 
circumstances. Rather, the native syntax is preferred. Keys 
exchanged with Key-Assign, however, may be used in this situation. 


2.4.5. MAC-Info 


This header is used to supply a Message Authenticity Check, providing 
both message authentication and integrity, computed from the message 
text, the time (optional -- to prevent replay attack), and a shared 
secret between client and server. The MAC should be computed over the 
encapsulated content of the S-HTTP message. S-HTTP/1.1 defined that 
MACs should be computed using the following algorithm (’||’ means 
concatenation): 


MAC = hex (H (Message || [<time>] ||<shared key>)) 


The time should be represented as an unsigned 32 bit quantity 
representing seconds since 00:00:00 GMT January 1, 1970 (the UNIX 
epoch), in network byte order. The shared key format is a local 
matter. 


Recent research [VANO95] has demonstrated some weaknesses in this 
approach, and this memo introduces a new construction, derived from 
[RFC-2104]. In the name of backwards compatibility, we retain the 
previous constructions with the same names as before. However, we 
also introduce a new series of names (See Section 3.2.4.8 for the 
names) that obey a different (hopefully stronger) construction. (^ 
means bitwise XOR) 


HMAC = hex(H(K’ ^ pad2 || H(K’ ^ pad1 ||[<time>]|| Message))) 
padl the byte 0x36 repeated enough times to fill out a 
hash input block. (I.e. 64 times for both MD5 and SHA-1) 
pad2 = the byte 0x5c repeated enough times to fill out a 
hash input block. 
K’ = H(<shared key>) 


The original HMAC construction is for the use of a key with length 
equal to the length of the hash output. Although it is considered 
safe to use a key of a different length (Note that strength cannot be 
increased past the length of the hash function itself, but can be 
reduced by using a shorter key.) [KRAW96b] we hash the original key 
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to permit the use of shared keys (e.g. passphrases) longer than the 
length of the hash. It is noteworthy (though obvious) that this 
technique does not increase the strength of short keys. 


The format of the MAC-Info line is: 


MAC-Info = 

"MAC=IRLEO" MaM [hex-time], 

hash-alg, hex-hash-data, key-spec 

hex-time = <unsigned seconds since Unix epoch represented as HEX> 


hash-alg = <hash algorithms from section 3.2.4.8> 
hex-hash-data = <computation as described above represented as HEX> 
Key-Spec = "null" | "dek" | Key-ID 


Key-Ids can refer either to keys bound using the Key-Assign header 
line or those bound in the same fashion as the Outband method 
described later. The use of a ’Null’ key-spec implies that a zero 
length key was used, and therefore that the MAC merely represents a 
hash of the message text and (optionally) the time. The special 
key-spec ‘DEK’ refers to the Data Exchange Key used to encrypt the 
following message body (it is an error to use the DEK key-spec in 
situations where the following message body is unencrypted). 


If the time is omitted from the MAC-Info line, it should simply not 
be included in the hash. 


Note that this header line can be used to provide a more advanced 
equivalent of the original HTTP Basic authentication mode in that the 
user Can be asked to provide a username and password. However, the 
password remains private and message integrity can be assured. 
Moreover, this can be accomplished without encryption of any kind. 


In addition, MAC-Info permits fast message integrity verification (at 
the loss of non-repudiability) for messages, provided that the 
participants share a key (possibly passed using Key-Assign in a 
previous message). 


Note that some Content-Privacy-Domains, notably likely future 
revisions of MOSS and CMS may have support for symmetric integrity 
protection The MAC-Info field need not be used in such circumstances. 
Rather, the native syntax is preferred. Keys exchanged with Key- 
Assign, however, may be used in this situation. 


2.5. Content 


The content of the message is largely dependent upon the values of 
the Content-Privacy-Domain and Content-Transfer-Encoding fields. 
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For a CMS message, with ’8BIT’ Content-Transfer-Encoding, the content 
should simply be the CMS message itself. 


If the Content-Privacy-Domain is MOSS, the content should consist of 
a MOSS Security Multipart as described in RFC1847. 


It is expected that once the privacy enhancements have been removed, 
the resulting (possibly protected) contents will be a normal HTTP 
request. Alternately, the content may be another Secure-HTTP message, 
in which case privacy enhancements should be unwrapped until clear 
content is obtained or privacy enhancements can no longer be removed. 
(This permits embedding of enhancements, such as sequential Signed 
and Enveloped enhancements.) Provided that all enhancements can be 
removed, the final de-enhanced content should be a valid HTTP request 
(or response) unless otherwise specified by the Content-Type line. 


Note that this recursive encapsulation of messages potentially 
permits security enhancements to be applied (or removed) for the 
benefit of intermediaries who may be a party to the transaction 
between a client and server (e.g., a proxy requiring client 
authentication). How such intermediaries should indicate such 
processing is described in Section 7.2.1. 


Encapsulation Format Options 
1. Content-Privacy-Domain: CMS 


Content-Privacy-Domain ’CMS’ follows the form of the CMS standard 
(see Appendix). 


Message protection may proceed on two orthogonal axes: signature and 
encryption. Any message may be either signed, encrypted, both, or 
neither. Note that the 'auth” protection mode of S-HTTP is provided 
independently of CMS coding via the MAC-Info header of section 2.3.6 
since CMS does not support a 'KeyDigestedData” type, although it does 
support a 'DigestedData” type. 


.1.1. Signature 


This enhancement uses the ’SignedData’ type of CMS. When digital 
signatures are used, an appropriate certificate may either be 
attached to the message (possibly along with a certificate chain) as 
specified in CMS or the sender may expect the recipient to obtain its 
certificate (and/or chain) independently. Note that an explicitly 
allowed instance of this is a certificate signed with the private 
component corresponding to the public component being attested to. 
This shall be referred to as a self-signed certificate. What, if any, 
weight to give to such a certificate is a purely local matter. In 
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either case, a purely signed message is precisely CMS compliant. 
2.6.1.2. Encryption 


2.6.1.2.1. Encryption -- normal, public key 


This enhancement is performed precisely as enveloping (using either ' 
EnvelopedData’ types) under CMS. A message encrypted in this fashion, 
signed or otherwise, is CMS compliant. To have a message which is 
both signed and encrypted, one simply creates the CMS SignedData 
production and encapsulates it in EnvelopedData as described in CMS. 


2.6.1.2.2. Encryption -- prearranged key 


This uses the 'EncryptedData” type of CMS. In this mode, we encrypt 
the content using a DEK encrypted under cover of a prearranged 
session key (how this key may be exchanged is discussed later), with 
key identification information specified on one of the header lines. 
The IV is in the EncryptedContentInfo type of the EncryptedData 
element. To have a message which is both signed and encrypted, one 
simply creates the CMS SignedData production and encapsulates it in 
EncryptedData as described in CMS. 


2.6.2. Content-Privacy-Domain: MOSS 


The body of the message should be a MIME compliant message with 
content type that matches the Content-Type line in the S-HTTP 
headers. Encrypted messages should use multipart/encrypted. Signed 
messages should use multipart/signed. However, since multipart/signed 
does not convey keying material, is is acceptable to use 
multipart/mixed where the first part is application/mosskey-data and 
the second part is multipart/mixed in order to convey certificates 
for use in verifying the signature. 


Implementation Note: When both encryption and signature are applied 
by the same agent, signature should in general be applied before 
encryption. 


2.6.3. Permitted HTTP headers 
2.6.3.1. Overview 


In general, HTTP [RFC-2616] headers should appear in the inner 
content (i.e. the message/http) of an S-HTTP message but should not 
appear in the S-HTTP message wrapper for security reasons. However, 
certain headers need to be visible to agents which do not have access 
to the encapsulated data. These headers may appear in the S-HTTP 
headers as well. 
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Please note that although brief descriptions of the general purposes 
of these headers are provided for clarity, the definitive reference 
is [RFC-2616]. 


2.6.3.2. Host 


The host header specificies the internet host and port number of the 
resource being requested. This header should be used to disambiguate 
among multiple potential security contexts within which this message 
could be interpreted. Note that the unwrapped HTTP message will have 


it’s own Host field (assuming it’s an HTTP/1.1 message). If these 
fields do not match, the server should respond with a 400 status 
code. 

2.6.3.3. Connection 


The Connection field has precisely the same semantics in S-HTTP 
headers as it does in HTTP headers. This permits persistent 
connections to be used with S-HTTP. 


3. Cryptographic Parameters 

3.1. Options Headers 
As described in Section 1.3.2, every S-HTTP request is (at least 
conceptually) preconditioned by the negotiation options provided by 
the potential receiver. The two primary locations for these options 


are 


1. In the headers of an HTTP Request/Response. 
2. In the HTML which contains the anchor being dereferenced. 


There are two kinds of cryptographic options which may be provided: 
Negotiation options, as discussed in Section 3.2 convey a potential 
message recipient’s cryptographic preferences. Keying options, as 
discussed in Section 3.3 provide keying material (or pointers to 
keying material) which may be of use to the sender when enhancing a 
message. 


Binding cryptographic options to anchors using HTML extensions is the 
topic of the companion document [SHTML] and will not be treated here. 
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3.2. Negotiation Options 
3.2.1. Negotiation Overview 


Both parties are able to express their requirements and preferences 
regarding what cryptographic enhancements they will permit/require 
the other party to provide. The appropriate option choices depend on 
implementation capabilities and the requirements of particular 
applications. 


A negotiation header is a sequence of specifications each conforming 
to a four-part schema detailing: 


Property -- the option being negotiated, such as bulk encryption 
algorithm. 

Value -- the value being discussed for the property, such as 
DES-CBC 

Direction -- the direction which is to be affected, namely: 
during reception or origination (from the perspective of the 
originator). 

Strength -- strength of preference, namely: required, optional, 
refused 


As an example, the header line: 
SHTTP-Symmetric-Content-Algorithms: recv-optional=DES-CBC,RC2 


could be thought to say: "You are free to use DES-CBC or RC2 for bulk 
encryption for encrypting messages to me." 


We define new headers (to be used in the encapsulated HTTP header, 
not in the S-HTTP header) to permit negotiation of these matters. 


3.2.2. Negotiation Option Format 


The general format for negotiation options is: 


Option = Field ":" Key-val ";" *(Key-val) 

Key-val = Key "=" Value *("," Value) 

Key = Mode"-"Action ; This is represented as one 
; token without whitespace 

Mode = "orig" | "recv" 

Action = "optional" | "required" | "refused" 
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The <Mode> value indicates whether this <Key-val> refers to what the 
agent’s actions are upon sending privacy enhanced messages as opposed 
to upon receiving them. For any given mode-action pair, the 
interpretation to be placed on the enhancements (<Value>s) listed is: 


"recv-optional:” The agent will process the enhancement if the 
other party uses it, but will also gladly process messages 
without the enhancement. 


"recv-required:” The agent will not process messages without 
this enhancement. 


"recv-refused:” The agent will not process messages with this 
enhancement. 


‘orig-optional:’ When encountering an agent which refuses this 
enhancement, the agent will not provide it, and when 
encountering an agent which requires it, this agent will provide 
its 


"orig-required:” The agent will always generate the enhancement. 
"orig-refused:” The agent will never generate the enhancement. 


The behavior of agents which discover that they are communicating 
with an incompatible agent is at the discretion of the agents. It is 
inappropriate to blindly persist in a behavior that is known to be 
unacceptable to the other party. Plausible responses include simply 
terminating the connection, or, in the case of a server response, 
returning ’Not implemented 501’. 


Optional values are considered to be listed in decreasing order of 
preference. Agents are free to choose any member of the intersection 
of the optional lists (or none) however. 


If any <Key-Val> is left undefined, it should be assumed to be set to 
the default. Any key which is specified by an agent shall override 
any appearance of that key in any <Key-Val> in the default for that 
field. 
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3.2.3. Parametrization for Variable-length Key Ciphers 


For ciphers with variable key lengths, values may be parametrized 
using the syntax <cipher>’ [’<length>’]’ 


For example, ’RSA[1024]’ represents a 1024 bit key for RSA. Ranges 
may be represented as 


<cipher>’ [’ <bound1>’ -' <bound2>’ ]” 


For purposes of preferences, this notation should be treated as if it 
read (assuming x and y are integers) 


<cipher>[x], <cipher>[x+1],...<cipher>[y] (if x<y) 
and 
<cipher>[x], <cipher>[x-1],...<cipher>[y] (if x>y) 
The special value 'inf” may be used to denote infinite length. 


Using simply <cipher> for such a cipher shall be read as the maximum 
range possible with the given cipher. 


3.2.4. Negotiation Syntax 
3.2.4.1. SHTTP-Privacy-Domains 


This header refers to the Content-Privacy-Domain type of section 
2.3.1. Acceptable values are as listed there. For instance, 


SHTTP-Privacy-Domains: orig-required=cms; 
recv-optional=cms,MOSS 


would indicate that the agent always generates CMS compliant 
messages, but can read CMS or MOSS (or, unenhanced messages). 


3.2.4.2. SHTTP-Certificate-Types 


This indicates what sort of Public Key certificates the agent will 
accept. Currently defined values are 'X.509” and 'X.509v3'. 


3.2.4.3. SHTTP-Key-Exchange-Algorithms 


This header indicates which algorithms may be used for key exchange. 
Defined values are ’DH’, ’RSA’, 'Outband” and ’Inband’. DH refers to 
Diffie-Hellman X9.42 style enveloping. [DH] RSA refers to RSA 
enveloping. Outband refers to some sort of external key agreement. 
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Inband refers to section 3.3.3.1. 


The expected common configuration of clients having no certificates 
and servers having certificates would look like this (in a message 
sent by the server): 


SHTTP-Key-Exchange-Algorithms: orig-optional=Inband, DH; 
recv-required=DH 


3.2.4.4. SHTTP-Signature-Algorithms 


This header indicates what Digital Signature algorithms may be used. 
Defined values are ’RSA’ [PKCS-1] and /NIST-DSS’ [FIPS-186] Since 
NIST-DSS and RSA use variable length moduli the parametrization 
syntax of section 3.2.3 should be used. Note that a key length 
specification may interact with the acceptability of a given 
certificate, since keys (and their lengths) are specified in public- 
key certificates. 


3.2.4.5. SHTTP-Message-Digest-Algorithms 
This indicates what message digest algorithms may be used. 
Previously defined values are ’RSA-MD2’ [RFC-1319], ’RSA-MD5’ [RFC- 
1321], 'NIST-SHS” [FIPS-180]. 


3.2.4.6. SHTTP-Symmetric-Content-Algorithms 


This header specifies the symmetric-key bulk cipher used to encrypt 


message content. Defined values are: 

DES-CBC -- DES in Cipher Block Chaining (CBC) mode [FIPS-81] 

DES-EDE-CBC -- 2 Key 3DES using Encrypt-Decrypt-Encrypt in outer 
CBC mode 

DES-EDE3-CBC -- 3 Key 3DES using Encrypt-Decrypt-Encrypt in outer 
CBC mode 

DESX-CBC -- RSA's DESX in CBC mode 

IDEA-CBC -- IDEA in CBC mode 

RC2-CBC -- RSA’s RC2 in CBC mode 

CDMF-CBC -- IBM's CDMF (weakened key DES) [JOHN93] in CBC mode 


Since RC2 keys are variable length, the syntax of section 3.2.3 
should be used. 
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3.2.4.7. SHTTP-Symmetric-Header-Algorithms 


This header specifies the symmetric-key cipher used to encrypt 
message headers. 


DES-ECB -- DES in Electronic Codebook (ECB) mode [FIPS-81] 
DES-EDE-ECB -- 2 Key 3DES using Encrypt-Decrypt-Encrypt in ECB mode 
DES-EDE3-ECB -- 3 Key 3DES using Encrypt-Decrypt-Encrypt in ECB mode 
DESX-ECB -- RSA’s DESX in ECB mode 

IDEA-ECB -- IDEA 

RC2-ECB -- RSA’s RC2 in ECB mode 

CDMF-ECB -- IBM’s CDMF in ECB mode 


Since RC2 is variable length, the syntax of section 3.2.3 should be 
used. 


3.2.4.8. SHTTP-MAC-Algorithms 


This header indicates what algorithms are acceptable for use in 
providing a symmetric key MAC. ’RSA-MD2’, 'RSA-MD5” and '*NIST-SHS” 
persist from S-HTTP/1.1 using the old MAC construction. The tokens ’ 
RSA-MD2-HMAC’, 'RSA-MD5-HMAC” and /’/NIST-SHS-HMAC’ indicate the new 


HMAC construction of 2.3.6 with the MD2, MD5, and SHA-1 algorithms 
respectively. 


3.2.4.9. SHTTP-Privacy-Enhancements 


This header indicates security enhancements to apply. Possible 
values are 'sign”, ‘encrypt’ and ’auth’ indicating whether messages 


are signed, encrypted, or authenticated (i.e., provided with a MAC), 
respectively. 


3.2.4.10. Your-Key-Pattern 


This is a generalized pattern match syntax to describe identifiers 


for a large number of types of keying material. The general syntax 
is: 


Your-Key-Pattern = 


"Your-Key-Pattern" ":" key-use "," pattern-info 
key-use = "cover-key" | "auth-key" | "signing-key" 
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3.2.4.10.1. Cover Key Patterns 


This header specifies desired values for key names used for 
encryption of transaction keys using the Prearranged-Key-Info syntax 
of section 2.3.5. The pattern-info syntax consists of a series of 
comma separated regular expressions. Commas should be escaped with 
backslashes if they appear in the regexps. The first pattern should 
be assumed to be the most preferred. 


3.2.4.10.2. Auth key patterns 


Auth-key patterns specify name forms desired for use for MAC 
authenticators. The pattern-info syntax consists of a series of 
comma separated regular expressions. Commas should be escaped with 
backslashes if they appear in the regexps. The first pattern should 
be assumed to be the most preferred. 


3.2.4.10.3. Signing Key Pattern 
This parameter describes a pattern or patterns for what keys are 


acceptable for signing for the digital signature enhancement. The 
pattern-info syntax for signing-key is: 


pattern-info = name-domain "," pattern-data 


The only currently defined name-domain is ’DN-1779’. This parameter 
specifies desired values for fields of Distinguished Names. DNs are 
considered to be represented as specified in RFC1779, the order of 
fields and whitespace between fields is not significant. 


All RFC1779 values should use ’,’ as a separator rather than ';', 
since ’;’ is used as a statement separator in S-HTTP. 


Pattern-data is a modified RFC1779 string, with regular expressions 
permitted as field values. Pattern match is performed field-wise, 
unspecified fields match any value (and therefore leaving the DN- 
Pattern entirely unspecified allows for any DN). Certificate chains 
may be matched as well (to allow for certificates without name 
subordination). DN chains are considered to be ordered left-to-right 
with the issuer of a given certificate on its immediate right, 
although issuers need not be specified. A trailing ’.’ indicates that 
the sequence of DNs is absolute. I.e. that the one furthest to the 
right is a root. 
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The syntax for the pattern values is, 


Value = DN-spec *("," Dn-spec) ["."] 


Dn-spec = "/" *(Field-spec) "/" 
Field-spec := Attr = "Pattern" 
Attr = "CN" | "g" | "ST" | "o" | 
"ou" | "TOT | <or as appropriate> 


Pattern = <POSIX 1003.2 regular expressions> 


For example, to request that the other agent sign with a key 
certified by the RSA Persona CA (which uses name subordination) one 
could use the expression below. Note the use of RFC1779 quoting to 
protect the comma (an RFC1779 field separator) and the POSIX 1003.2 
quoting to protect the dot (a regular expression metacharacter). 


Your-Key-Pattern: signing-key, DN-1779, 
/OU=Persona Certificate, O="RSA Data Security, 
Inc\."/ 


3.2.4.11. Example 
A representative header block for a server follows. 


SHTTP-Privacy-Domains: recv-optional=MOSS, CMS; 
orig-required=CMS 

SHTTP-Certificate-Types: recv-optional=X.509; 
orig-required=X.509 
1TTP-Key-Exchange-Algorithms: recv-required=DH; 
orig-optional=Inband, DH 
SHTTP-Signature-Algorithms: orig-required=NIST-DSS; 
recv-required=NIST-DSS 
SHTTP-Privacy-Enhancements: orig-required=sign; 
orig-optional=encrypt 


SH 


3.2.4.12. Defaults 


Explicit negotiation parameters take precedence over default values. 
For a given negotiation option type, defaults for a given mode-action 
pair (such as ‘’orig-required’) are implicitly merged unless 
explicitly overridden. 


The default values (these may be negotiated downward or upward) are: 


SHTTP-Privacy-Domains: orig-optional=CMS; 
recv-optional=CMS 
SHTTP-Certificate-Types: orig-optional=X.509; 
recv-optional=X.509 
SHTTP-Key-Exchange-Algorithms: orig-optional=DH, Inband, Outband; 
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recv-optional=DH, Inband, Outband 

SHTTP-Signature-Algorithms: orig-optional=NIST-DSS; 
recv-optional=NIST-DSS 
SHTTP-Message-Digest-Algorithms: orig-optional=RSA-MD5; 
recv-optional=RSA-MD5 
1TTP-Symmetric-Content-Algorithms: orig-optional=DES-CBC; 
recv-optional=DES-CBC 
SHTTP-Symmetric-Header-Algorithms: orig-optional=DES-ECB; 
recv-optional=DES-ECB 
SHTTP-Privacy-Enhancements: orig-optional=sign,encrypt, auth; 

recv-required=encrypt; 

recv-optional=sign, auth 


n 
i 


3.3. Non-Negotiation Headers 


There are a number of options that are used to communicate or 
identify the potential recipient’s keying material. 


3.3.1. Encryption-Identity 


This header identifies a potential principal for whom the message 
described by these options could be encrypted; Note that this 
explicitly permits return encryption under (say) public key without 
the other agent signing first (or under a different key than that of 
the signature). The syntax of the Encryption-Identity line is: 


Encryption-Identity = 
"Encryption Identity" ":" name-class,key-sel, name-arg 
name-class = "DN-1779" | MOSS name forms 
The name-class is an ASCII string representing the domain within 
which the name is to be interpreted, in the spirit of MOSS. In 
addition to the MOSS name forms of RFC1848, we add the DN-1779 name 
form to represent a more convenient form of distinguished name. 
3.3.1.1. DN-1779 Name Class 
The argument is an RFC-1779 encoded DN. 
3.3.2. Certificate-Info 
In order to permit public key operations on DNs specified by 
Encryption-Identity headers without explicit certificate fetches by 
the receiver, the sender may include certification information in the 
Certificate-Info option. The format of this option is: 


Certificate-Info: <Cert-Fmt>”,'<Cert-Group> 


<Cert-Fmt> should be the type of <Cert-Group> being presented. 
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Defined values are ’PEM’ and ’CMS’. CMS certificate groups are 
provided as a base-64 encoded CMS SignedData message containing 
sequences of certificates with or without the SignerInfo field. A PEM 
format certificate group is a list of comma-separated base64-encoded 
PEM certificates. 

Multiple Certificate-Info lines may be defined. 


3.3.3. Key-Assign 


This option serves to indicate that the agent wishes to bind a key to 
a symbolic name for (presumably) later reference. 


The general syntax of the key-assign header is: 


Key-Assign = 


"Key-Assign" ":" Method "," Key-Name "," 
Lifetime "," Ciphers ";" Method-args 
Key-name = string 
Lifetime = "this" | "reply" | we 
Method ="inband" 
Ciphers = "null" | Cipher+ 
Cipher" = <Header cipher from section 3.2.4.7> 
ky = "4" | won 


Key-Name is the symbolic name to which this key is to be bound. 
Ciphers is a list of ciphers for which this key is potentially 
applicable (see the list of header ciphers in section 3.2.4.7). The 
keyword ‘null’ should be used to indicate that it is inappropriate 
for use with ANY cipher. This is potentially useful for exchanging 
keys for MAC computation. 


Lifetime is a representation of the longest period of time during 
which the recipient of this message can expect the sender to accept 
that key. ‘this’ indicates that it is likely to be valid only for 
reading this transmission. ‘reply’ indicates that it is useful for a 
reply to this message. If a Key-Assign with the reply lifetime 
appears in a CRYPTOPTS block, it indicates that it is good for at 
least one (but perhaps only one) dereference of this anchor. An 
unspecified lifetime implies that this key may be reused for an 
indefinite number of transactions. 


Method should be one of a number of key exchange methods. The only 
currently defined value is ’inband’ referring to Inband keys (i.e., 
direct assignment). 
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This header line may appear either in an unencapsulated header or in 
an encapsulated message, though when an uncovered key is being 
directly assigned, it may only appear in an encrypted encapsulated 
content. Assigning to a key that already exists causes that key to be 
overwritten. 


Keys defined by this header are referred to elsewhere in this 
specification as Key-IDs, which have the syntax: 


Key-ID = method ":" key-name 
3.3.3.1. Inband Key Assignment 


This refers to the direct assignment of an uncovered key to a 
symbolic name. Method-args should be just the desired session key 
encoded in hexidecimal as in: 


Key-Assign: inband, akey, reply, DES—ECB; 012345678 9abcdef 


Short keys should be derived from long keys by reading bits from left 
to right. 


Note that inband key assignment is especially important in order to 
permit confidential spontaneous communication between agents where 
one (but not both) of the agents have key pairs. However, this 
mechanism is also useful to permit key changes without public key 
computations. The key information is carried in this header line must 
be in the inner secured HTTP request, therefore use in unencrypted 
messages is not permitted. 


3.3.4. Nonces 


Nonces are opaque, transient, session-oriented identifiers which may 
be used to provide demonstrations of freshness. Nonce values are a 
local matter, although they are might well be simply random numbers 
generated by the originator. The value is supplied simply to be 
returned by the recipient. 


3.3.4.1. Nonce 
This header is used by an originator to specify what value is to be 
returned in the reply. The field may be any value. Multiple nonces 


may be supplied, each to be echoed independently. 


The Nonce should be returned in a Nonce-Echo header line. See section 
4.1.1. 
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3.4. Grouping Headers With SHTTP-Cryptopts 


In order for servers to bind a group of headers to an HTML anchor, it 
is possible to combine a number of headers on a single S-HTTP 
Cryptopts header line. The names of the anchors to which these 
headers apply is indicated with a ’scope’ parameter. 


3.4.1. SHTTP-Cryptopts 


This option provides a set of cryptopts anda list of references to 
which it applies. (For HIML, these references would be named using 
the NAME tag). The names are provided in the scope attribute as a 
comma separated list and separated from the next header line by a 
semicolon. The format for the SHTTP-Cryptopts line is: 


SHTTP-Cryptopts = 


"SHTTP-Cryptopts" ":" scope ";" cryptopt-list 
scope = "scope="<tag-spec> ; This is all one token without whitespace 
tag-spec = tag *("," tag) | pn 
cryptopt-list = cryptopt *(";" cryptopt) 


cryptopt = <S-HTTP cryptopt lines described below> 
tag = <value used in HTML anchor NAME attribute> 


For example: 


SHTTP-Cryptopts: scope=tagl,tag2; 
SHTTP-Privacy-Domains: 
orig-required=cms; recv-optional=cms,MOSS 


If a message contains both S-HTTP negotiation headers and headers 
grouped on SHTTP-Cryptopts line(s), the other headers shall be taken 
to apply to all anchors not bound on the SHTTP-Cryptopts line (s). 
Note that this is an all-or-nothing proposition. That is, if a 
SHTTP-Cryptopts header binds options to a reference, then none of 
these global options apply, even if some of the options headers do 
not appear in the bound options. Rather, the S-HTTP defaults found in 
Section 3.2.4.11 apply. 


4. New Header Lines for HTTP 
Two non-negotiation header lines for HTTP are defined here. 

4.1. Security-Scheme 
All S-HTTP compliant agents must generate the Security-Scheme header 
in the headers of all HTTP messages they generate. This header 


permits other agents to detect that they are communicating with an 
S-HTTP compliant agent and generate the appropriate cryptographic 
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options headers. 


For implementations compliant with this specification, the value must 
be 'S-HTTP/1.4'. 


4.1.1. Nonce-Echo 
The header is used to return the value provided in a previously 
received Nonce: field. This has to go in the encapsulated headers so 


that it an be cryptographically protected. 


Sz (Retriable) Server Status Error Reports 


We describe here the special processing appropriate for client 
retries in the face of servers returning an error status. 


5.1. Retry for Option (Re)Negotiation 


A server may respond to a client request with an error code that 
indicates that the request has not completely failed but rather that 
the client may possibly achieve satisfaction through another request. 
HTTP already has this concept with the 3XX redirection codes. 


In the case of S-HTTP, it is conceivable (and indeed likely) that the 
server expects the client to retry his request using another set of 
cryptographic options. E.g., the document which contains the anchor 
that the client is dereferencing is old and did not require digital 
signature for the request in question, but the server now has a 
policy requiring signature for dereferencing this URL. These options 
should be carried in the header of the encapsulated HTTP message, 
precisely as client options are carried. 


The general idea is that the client will perform the retry in the 
manner indicated by the combination of the original request and the 
precise nature of the error and the cryptographic enhancements 
depending on the options carried in the server response. 


The guiding principle in client response to these errors should be to 
provide the user with the same sort of informed choice with regard to 
dereference of these anchors as with normal anchor dereference. For 
instance, in the case above, it would be inappropriate for the client 
to sign the request without requesting permission for the action. 
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5.2. Specific Retry Behavior 
5.2.1. Unauthorized 401, PaymentRequired 402 


The HTTP errors '“Unauthorized 401’, '“PaymentRequired 402’ represent 
failures of HTTP style authentication and payment schemes. While S- 
HTTP has no explicit support for these mechanisms, they can be 
performed under S-HTTP while taking advantage of the privacy services 
offered by S-HTTP. (There are other errors for S-HTTP specific 
authentication errors.) 


5.2.2. 420 SecurityRetry 


This server status reply is provided so that the server may inform 
the client that although the current request is rejected, a retried 
request with different cryptographic enhancements is worth 
attempting. This header shall also be used in the case where an HTTP 
request has been made but an S-HTTP request should have been made. 
Obviously, this serves no useful purpose other than signalling an 
error if the original request should have been encrypted, but in 
other situations (e.g. access control) may be useful. 


5.2.2.1. SecurityRetries for S-HTTP Requests 


In the case of a request that was made as an SHTTP request, it 
indicates that for some reason the cryptographic enhancements applied 
to the request were unsatisfactory and that the request should be 
repeated with the options found in the response header. Note that 
this can be used as a way to force a new public key negotiation if 
the session key in use has expired or to supply a unique nonce for 
the purposes of ensuring request freshness. 


5.2.2.2. SecurityRetries for HTTP Requests 


If the 420 code is returned in response to an HTTP request, it 
indicates that the request should be retried using S-HTTP and the 
cryptographic options indicated in the response header. 


5.2.3. 421 BogusHeader 


This error code indicates that something about the S-HTTP request was 
bad. The error code is to be followed by an appropriate explanation, 


e.g.: 


421 BogusHeader Content-Privacy-Domain must be specified 
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5.2.4. 422 SHTTP Proxy Authentication Required 


This response is analagous to the 420 response except that the 
options in the message refer to enhancements that the client must 
perform in order to satisfy the proxy. 


5.2.5. 320 SHTTP Not Modifed 


This response code is specifically for use with proxy-server 
interaction where the proxy has placed the If-Modified-Since header 
in the S-HTTP headers of its request. This response indicates that 
the following S-HTTP message contains sufficient keying material for 
the proxy to forward the cached document for the new requestor. 


In general, this takes the form of an S-HTTP message where the actual 
enhanced content is missing, but all the headers and keying material 
are retained. (I.e. the optional content section of the CMS message 
has been removed.) So, if the original response was encrypted, the 
response contains the original DEK re-covered for the new recipient. 
(Notice that the server performs the same processing as it would have 
in the server side caching case of 7.1 except that the message body 
is elided.) 


5.2.6. Redirection 3XX 


These headers are again internal to HTTP, but may contain S-HTTP 
negotiation options of significance to S-HTTP. The request should be 
redirected in the sense of HTTP, with appropriate cryptographic 
precautions being observed. 


5.3. Limitations On Automatic Retries 


Permitting automatic client retry in response to this sort of server 
response permits several forms of attack. Consider for the moment 
the simple credit card case: 


The user views a document which requires his credit card. The 
user verifies that the DN of the intended recipient is acceptable 
and that the request will be encrypted and dereferences the 
anchor. The attacker intercepts the server's reply and responds 
with a message encrypted under the client’s public key containing 
the Moved 301 header. If the client were to automatically perform 
this redirect it would allow compromise of the user’s credit 
card. 
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5.3.1. Automatic Encryption Retry 


This shows one possible danger of automatic retries -- potential 
compromise of encrypted information. While it is impossible to 
consider all possible cases, clients should never automatically 
reencrypt data unless the server requesting the retry proves that he 
already has the data. So, situations in which it would be acceptable 
to reencrypt would be if: 


1. The retry response was returned encrypted under an inband key 
freshly generated for the original request. 

2. The retry response was signed by the intended recipient of the 
original request. 

3. The original request used an outband key and the response is 
encrypted under that key. 


This is not an exhaustive list, however the browser author would be 
well advised to consider carefully before implementing automatic 
reencryption in other cases. Note that an appropriate behavior in 
cases where automatic reencryption is not appropriate is to query the 
user for permission. 


5.3.2. Automatic Signature Retry 
Since we discourage automatic (without user confirmation) signing in 
even the usual case, and given the dangers described above, it is 
prohibited to automatically retry signature enchancement. 


5.3.3. Automatic MAC Authentication Retry 


Assuming that all the other conditions are followed, it is 
permissible to automatically retry MAC authentication. 


6. Other Issues 
6.1. Compatibility of Servers with Old Clients 
Servers which receive requests in the clear which should be secured 


should return 'SecurityRetry 420’ with header lines set to indicate 
the required privacy enhancements. 


6.2. URL Protocol Type 


We define a new URL protocol designator, 'shttp'. Use of this 
designator as part of an anchor URL implies that the target server is 
S-HTTP capable, and that a dereference of this URL should undergo S- 
HTTP processing. 
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Note that S-HTTP oblivious agents should not be willing to 
dereference a URL with an unknown protocol specifier, and hence 
sensitive data will not be accidentally sent in the clear by users of 
non-secure clients. 


6.3. Browser Presentation 
6.3.1. Transaction Security Status 


While preparing a secure message, the browser should provide a visual 
indication of the security of the transaction, as well as an 
indication of the party who will be able to read the message. While 
reading a signed and/or enveloped message, the browser should 
indicate this and (if applicable) the identity of the signer. Self- 
signed certificates should be clearly differentiated from those 
validated by a certification hierarchy. 


6.3.2. Failure Reporting 


Failure to authenticate or decrypt an S-HTTP message should be 
presented differently from a failure to retrieve the document. 
Compliant clients may at their option display unverifiable documents 
but must clearly indicate that they were unverifiable in a way 
clearly distinct from the manner in which they display documents 
which possessed no digital signatures or documents with verifiable 
signatures. 


6.3.3. Certificate Management 


Clients shall provide a method for determining that HTTP requests are 
to be signed and for determining which (assuming there are many) 
certificate is to be used for signature. It is suggested that users 
be presented with some sort of selection list from which they may 
choose a default. No signing should be performed without some sort of 
explicit user interface action, though such action may take the form 
of a persistent setting via a user preferences mechanism (although 
this is discouraged.) 


6.3.4. Anchor Dereference 


Clients shall provide a method to display the DN and certificate 
chain associated with a given anchor to be dereferenced so that users 
may determine for whom their data is being encrypted. This should be 
distinct from the method for displaying who has signed the document 
containing the anchor since these are orthogonal pieces of encryption 
information. 
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7. Implementation Notes 
7.1. Preenhanced Data 


While S-HTTP has always supported preenhanced documents, in previous 
versions it was never made clear how to actually implement them. 
This section describes two methods for doing so: preenhancing the 
HTTP request/response and preenhancing the underlying data. 


7.1.1. Motivation 


The two primary motivations for preenhanced documents are security 
and performance. These advantages primarily accrue to signing but may 
also under special circumstances apply to confidentiality or 
repudiable (MAC-based) authentication. 


Consider the case of a server which repeatedly serves the same 
content to multiple clients. One such example would be a server which 
serves catalogs or price lists. Clearly, customers would like to be 
able to verify that these are actual prices. However, since the 
prices are typically the same to all comers, confidentiality is not 
an issue. (Note: see Section 7.1.5 below for how to deal with this 
Case as well). 


Consequently, the server might wish to sign the document once and 
simply send the cached signed document out when a client makes a new 
request, avoiding the overhead of a private key operation each time. 
Note that conceivably, the signed document might have been generated 
by a third party and placed in the server's cache. The server might 
not even have the signing key! This illustrates the security benefit 
of presigning: Untrusted servers can serve authenticated data without 
risk even if the server is compromised. 


7.1.2. Presigned Requests/Responses 


The obvious implementation is simply to take a single 
request/response, cache it, and send it out in situations where a new 
message would otherwise be generated. 


7.1.3. Presigned Documents 


It is also possible using S-HTTP to sign the underlying data and send 
it as an S-HTTP messsage. In order to do this, one would take the 
signed document (a CMS or MOSS message) and attach both S-HTTP 
headers (e.g. the S-HTTP request/response line, the Content-Privacy- 
Domain) and the necessary HTTP headers (including a Content-Type that 
reflects the inner content). 
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SECURE * Secure-HTTP/1.4 
Content-Type: text/html 
Content-Privacy-Domain: CMS 


Random signed message here... 


This message itself cannot be sent, but needs to be recursively 
encapsulated, as described in the next section. 


7.1.4. Recursive Encapsulation 


As required by Section 7.3, the result above needs to be itself 
encapsulated to protect the HTTP headers. the obvious case [and the 
one illustrated here] is when confidentiality is required, but the 
auth enhancement or even the null transform might be applied instead. 
That is, the message shown above can be used as the inner content of 
a new S-HTTP message, like so: 


SECURE * Secure-HTTP/1.4 
Content-Type: application/s-http 


Content-Privacy-Domain: CMS 


Encrypted version of the message above... 


To unfold this, the receiver would decode the outer S-HTTP message, 
reenter the (S-)HTTP parsing loop to process the new message, see 
that that too was S-HTTP, decode that, and recover the inner content. 


Note that this approach can also be used to provide freshness of 
server activity (though not of the document itself) while still 
providing nonrepudiation of the document data if a NONCE is included 
in the request. 


7.1.5. Preencrypted Messages 


Although preenhancement works best with signature, it can also be 
used with encryption under certain conditions. Consider the situation 
where the same confidential document is to be sent out repeatedly. 
The time spent to encrypt can be saved by caching the ciphertext and 
simply generating a new key exchange block for each recipient. [Note 
that this is logically equivalent to a multi- recipient message as 
defined in both MOSS and CMS and so care must be taken to use proper 
PKCs-1 padding if RSA is being used since otherwise, one may be open 
to a low encryption exponent attack [HAST96]. 
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7.2. Proxy Interaction 


The use of S-HTTP presents implementation issues to the use of HTTP 
proxies. While simply having the proxy blindly forward responses is 
straightforward, it would be preferable if S-HTTP aware proxies were 
still able to cache responses in at least some circumstances. In 
addition, S-HTTP services should be usable to protect client-proxy 
authentication. This section describes how to achieve those goals 
using the mechanisms described above. 


7.2.1. Client-Proxy Authentication 


When an S-HTTP aware proxy receives a request (HTTP or S-HTTP) that 
(by whatever access control rules it uses) it requires to be S-HTTP 
authenticated (and if it isn't already so), it should return the 422 
response code (5.7.4). 


When the client receives the 422 response code, it should read the 
cryptographic options that the proxy sent and determine whether or 
not it is willing to apply that enhancement to the message. If the 
client is willing to meet these requirements, it should recursively 
encapsulate the request it previously sent using the appropriate 
options. (Note that since the enhancement is recursively applied, 
even clients which are unwilling to send requests to servers in the 
clear may be willing to send the already encrypted message to the 
proxy without further encryption.) (See Section 7.1 for another 
example of a recursively encapsulated message) 


When the proxy receives such a message, it should strip the outer 
encapsulation to recover the message which should be sent to the 
server. 

8. Implementation Recommendations and Requirements 
All S-HTTP agents must support the MD5 message digest and MAC 
authentication. As of S-HTTP/1.4, all agents must also support the 
RSA-MD5-HMAC construction. 
All S-HTTP agents must support Outband, Inband, and DH key exchange. 
All agents must support encryption using DES-CBC. 


Agents must support signature generation and verification using 
NIST-DSS. 
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9. Protocol Syntax Summary 


We present below a summary of the main syntactic features of S- 
HTTP/1.4, excluding message encapsulation proper. 


9.1.  S-HTTP (Unencapsulated) Headers 


Content-Privacy-Domain: (’CMS’ | ’MOSS’) 

Prearranged-Key-Info: <Hdr-Cipher>, <Key>,<Key-ID> 

Content-Type: 'message/http” 

MAC-Info: [hex(timeofday)’,’]<hash-alg>’,’hex(<hash-data>)’,’ 
<key-spec> 


9.2. HTTP (Encapsulated) Non-negotiation Options 


Key-Assign: <Method>’,’<Key-Name>’,’<Lifetime>’,’ 
<Ciphers>’ ;’<Method-args> 

Encryption-Identity: <name-class>’,’<key-sel>’,’<name-args> 

Certificate-Info: <Cert-Fmt>’ ,’<Cert-Group> 

Nonce: <string> 

Nonce-Echo: <string> 


9.3. Encapsulated Negotiation Options 


HTTP-Cryptopts: <scope>’;’<string>(,<string>) * 

HTTP-Privacy-Domains: (’CMS’ | ' MOSS’) 

HTTP-Certificate-Types: (’X.509’) 

ITTP-Key-Exchange-Algorithms: (’DH’, ’RSA’ | ’Inband’ | ‘Outband’ ) 
HTTP-Signature-Algorithms: (’RSA’ | "NIST-DSS’ ) 
ITTP-Message-Digest-Algorithms: (’RSA-MD2’ | ’RSA-MD5’ | ‘NIST-SHS’ 
"RSA-MD2-HMAC', 'RSA-MD5-HMAC', 'NIST-SHS-HMAC') 
SHTTP-Symmetric-Content-Algorithms: (’DES-CBC’ | 'DES-EDE-CBC'” | 
"DES-EDE3-CBC* | ’DESX-CBC’ | ’CDMF-CBC’ | ’IDEA-CBC’ | 
"RC2-CBC'” ) 


NNnNNNNN 
m 


SHTTP-Symmetric-Header-Algorithms: ('DES-ECB” | ’DES-EDE-ECB' | 
"DES-EDE3-EBC” | 'DESX-ECB” | ’CDMF-ECB’ | ’IDEA-ECB’ | 
"RC2-ECB') 

SHTTP-Privacy-Enhancements: (’sign’ | ‘encrypt’ | ‘auth’ ) 


Your-Key-Pattern: <key-use>’,’<pattern-info> 
9.4. HTTP Methods 


Secure * Secure-HTTP/1.4 
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9.5. Server Status Reports 


Secure-HTTP/1.4 200 OK 
SecurityRetry 420 
BogusHeader 421 <reason> 


10. An Extended Example 


We provide here a contrived example of a series of S-HTTP requests 
and replies. Rows of equal signs are used to set off the narrative 
from sample message traces. Note that the actual encrypted or signed 
message bodies would normally be binary garbage. In an attempt to 
preserve readability while still using (mostly) genuine messages, the 
bodies of the requests have been base64 encoded. To regenerate actual 
S-HTTP messages, it is necessary to remove the base64 encoding from 
the message body. 


10.1. A request using RSA key exchange with Inband key reply 


Alice, using an S-HTTP-capable client, begins by making an HTTP 
request which yields the following response page: 


200 OK HTTP/1.0 

Server-Name: Navaho-0.1.3.3alpha 

Certificate-Info: CMS, MIAGCSqGSIb3DQEHAqCAMIACAQEXADCABgkgh 
kiG9IwOBBwEAAKCAM 
TIBrTCCAUkCAgC2MA0GCSqGS Ib3DQEBAgUAME0xC zZAJUBgNVBAYTA1LVTMSAwH 
gYDVOOKEXdSUOEGRGFOYSBTZWN1cm10eSwgSW5 jLJECMBOGALUECXMTUGVyc 
29uYSBDZXJ0aWZpY2F0ZTAeFw0OSNDAOMDkwMDUWMzdaFw0 5NDA4MDIxODM4N 
TdaMGcxCzAJBgGNVBAYTA1VTMSAwHgYDVOOKExdSU0EgRGFOYSBTZWN1cm10e 
SwgSW5 jJLJECMBoGA1LUECXMTUGVyc2 9uYSBDZXJ0aWZpY2FO0ZTEYMBYGA1UEA 
xMPU2VOZWMgOXN0cm9ub215MFwwDOYJKoZIhvcNAQEBBQADSwAwSAJBAMy80Q 
cW7RMrB4sTdQ8Nmb2DFmJmkWn+el+NdeamIDE1X/qw9mIQu4xNj1FfepfINx 
zPvA0OtMKhy6+bkr1lyMEU8CAWEAATANBgkqhkiG9wOBAQIFAANPAAYn74jDgi 
rhilL4wnP 8nGzUisGSpsFsF4/7z2P2wqne6Qk8Cg/Dstu3RyaN7 8vAMGP 8d8 
2H5+Ndfhi2mRp4YHiGHzOH1K6VbP fnyvS2wdjCCAccwggF RAGUCQAAAFDANB 
gkqhkiG9w0BAQIFADBfMOswCOYDVOOGEwWJVUzZEgMB4GA1UECHMXU1INBIERhd 
GEgU2V3dXJpdAHksIEluYy4xLjAsBgNVBAsTJUxvdyBBc3N1cmFuY2UgQ2Vyd 
GlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTQWMTA3MDAWMDAwWhcNOTYwMTA3M 
jMLOTU5WjBNMOswCOYDVOQGEWJVUZEGMB4GA1UEChMXULNBIERhdGEgU2Vjd 
XJpdHksIEluYy4xHDAaBgNVBASTE1B1cnNvbmEgQ2VydGlmaWNhdGUwaTANB 
gkqhk iG9w0BAQEFAANYADBVAk 4GqghQDa9Xi /2zAdYEqUVICYhH1ILNIFpI9txX 
Q1m6zZ39PYXK8UhojJOES7kKWRV8hCO04vqkOKwndWbzVtvoHOOmP 8nOkkuBitA 
QvgF oORcgOUCAWEAATANBgkqhkiG9w0BAQIFAANNAD/5U07xDdp4 9oZm9GONc 
PhZcWle+nojLvHXWAU/CBkwfcR+FSf4h05eFulAjYv6Wqf430Xe9Et5+3gnM 
Tigq4LnwgTdA8xQ0X4e1lJz90z00bkE3XVOJVAtCFcmiing80RB8AAAMYAAAAAAA 
AAAAA== 
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Encryption-Identity: DN-1779, null, CN=Setec Astronomy, OU=Persona 
Certificate,O="RSA Data Security, Inc.", C=US; 
SHTTP-Privacy-Enhancements: recv-required=encrypt 


<A name=tagl HREF="shttp://www.setec.com/secret"> 
Don't read this. </A> 


An appropriate HTTP request to dereference this URL would be: 


GET /secret HTTP/1.0 

Security-Scheme: S-HTTP/1.4 

User-Agent: Web-O-Vision 1.2beta 

Accept: *.* 

Key-Assign: Inband,1,reply,des-ecb;7878787878787878 


The added Key-Assign line that would not have been in an ordinary 
HTTP request permits Bob (the server) to encrypt his reply to Alice, 
even though Alice does not have a public key, since they would share 
a key after the request is received by Bob. This request has the 
following S-HTTP encapsulation: 


Secure * Secure-HTTP/1.4 
Content-Type: message/http 
Content-Privacy-Domain: CMS 


MIAGCSqGSIb3DQEHAGCAMIACAQAXg9DCBqoIBADBTMEOXCzZzAJBgGNVBAYTA1VTMSAw 
HgYDVQOKEXdSUOEGRGFOYSBTZWNicm10eSwgSW5 jLJECMBOGALUECXMTUGVyc29u 
YSBDZXJ0aWZpY2F0ZOICALYwWDOYJKoZIhvcNAQEBBOQAEOCU/R+YCISUSV6XLil1HG 
CcNVzwagKcWzmT/rZ+du0v8Ggb700/d8H3xUVGO2LsX4kYGq2szw3j806eWhsmhf4oz 
1lvMAADCABgkqhkiG9w0BBwEwEQYFKw4DAgcECFif7BadX1w30IAEgZBNcMexKel6 
+mNxx8YOPukBCLObWas861vws/AgRkKPELmysBi5lco8MBCsWK/fCyrnxIRHsloK 
BXBV1sAhKkkusk1kCf/GbXSAphdSgG+d6LxrNZwHbBFOX6A2hYS63Iczd5bOVDDW 
Op2gcgUtMJq6k2LFrs4L7HHQRPP1QNJ6 j5mFP4xkzOCNIQynpD1rV6EECMIk/T7k 
1 JLSAAAAAAAAAAAAAA== 


The data between the delimiters is a CMS message, RSA enveloped for 
Setec Astronomy. 


Bob decrypts the request, finds the document in question, and is 
ready to serve it back to Alice. 
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An appropriate HTTP server response would be: 


HTTP/1.0 200 OK 
Security-Scheme: S-HTTP/1.4 
Content-Type: text/html 


Congratulations, you've won. 
<A href="/prize.html" 
CRYPTOPTS="Key-Assign: Inband,alicel, reply, des-ecb;020406080a0c0e0f; 
SHTTP-Privacy-Enhancements: recv-required=auth">Click here to 
claim your prize</A> 


This HTTP response, encapsulated as an S-HTTP message becomes: 


Secure * Secure-HTTP/1.4 

Content-Type: message/http 

Prearranged-Key-Info: des-ecb,697fa820df8a6e53,inband:1 
Content-Privacy-Domain: CMS 


MIAGCSqGS Ib3DQEHBQCAMIACAQAwgAYJKoZIhvcNAQcBMBEGBSsSOAwIHBAifqtdy 
x6uIMYCCARgvFzJtOZBn773DtmX1x037ck3gigqnVOWCOQAx5f+fesAiGaxMgqWcir 
r9XvTOnTOLgSQO/8tiLCDBEKdyCNgdcJAduy3D0r2sb5sNTTOTyL9uydG3w55vTnw 
aPbCPCWLudArI 1UHDZbnoJICrVehxG/sYX069M8V6VO8PsJS7//hh1lyM+0nekzQ5 
11p0j7uWKu4W0csr1lGqhLvEJan j6dQAGSTNCOOH3 jzEXGOXntgesk8poFPfHdt j0 
5RH4MuJRajDmoE3J1rNcnGl/BdHAd2JaCo6uZWGcnGAgVJ/TVfSVSwN5n1CK87tX1 
nL7DJwaPRYwxb3mnPKNq7ATiJPf5ul1 62MbwxrddmiE7e3sST7naSN+GS0ateY5X7 
AAAAAAAAAAA= 


The data between the delimiters is a CMS message encrypted under a 
randomly-chosen DEK which can be recovered by computing: 


DES-DECRYPT (inband:1, 697fa820df8a6e53) 


where ’inband:1’ is the key exchanged in the Key-Assign line in the 
original request. 
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10.2. A request using the auth enhancement 


There is a link on the HTML page that was just returned, 
dereferences, creating the HTTP message: 


GET /prize.html HTTP/1.0 
Security-Scheme: S-HTTP/1.4 
User-Agent: Web-O-Vision 1.1lbeta 
Accept: *.* 


Which, when encapsulated as an S-HTTP message, becomes: 


Secure * Secure-HTTP/1.4 
Content-Type: message/http 


August 1999 


which Alice 


MAC-Info:31ff8122,rsa-md5,b3ca14575b841b5fc7553e69%b0896c416,inband:alicel 


Content-Privacy-Domain: CMS 


MIAGCSqGSIb3DOEHAaCABGNHRVOgL3ByaXpl1LmhO0bWwgSFRUUC8xXL3JAKU2V3dXJp 
aHktU2NoZW110iBTLUKhUVFAvMS4xC1VzZXItOWdlbn06IFdl1YilPLVZpc21vbiAx 


LjFiZXRhCkF3jY2VwdDogKi 4qCgoAAAAA 


The data between the delimiters is a CMS 'Data” representation of the 


request. 


Rescorla & Schiffman Experimental 


[Page 39] 


RFC 2660 The Secure HyperText Transfer Protocol August 1999 


Appendix: A Review of CMS 


CMS ("Cryptographic Message Syntax Standard") is a cryptographic 
message encapsulation format, similar to PEM, based on RSA's PKCS-7 
cryptographic messaging syntax. 


CMS is only one of two encapsulation formats supported by S-HTTP, but 
it is to be preferred since it permits the least restricted set of 

negotiable options, and permits binary encoding. In the interest of 
making this specification more self-contained, we summarize CMS here. 


CMS is defined in terms of OSI’s Abstract Syntax Notation (ASN.1, 
defined in X.208), and is concretely represented using ASN.1’s Basic 
Encoding Rules (BER, defined in X.209). A CMS message is a sequence 
of typed content parts. There are six content types, recursively 
composable: 


Data -- Some bytes, with no enhancement. 


SignedData -- A content part, with zero or more signature 

blocks, and associated keying materials. Keying materials 

can be transported via the degenerate case of no signature 
blocks and no data. 


EnvelopedData -- One or more (per recipient) key exchange 
blocks and an encrypted content part. 


DigestedData -- A content part with a single digest block. 


EncryptedData -- An encrypted content part, with key 
materials externally provided. 


Here we will dispense with convention for the sake of ASN.1-impaired 
readers, and present a syntax for CMS in informal BNF (with much 
gloss). In the actual encoding, most productions have explicit tag 
and length fields. 


*Content 
Data | SignedData | EnvelopedData | 
DigestedData | EncryptedData 


Message 
Content 


Data = Bytes 
SignedData = *DigestAlg Content *Certificates 
*CRLs SignerInfo* 
EnvelopedData = *RecipientInfo BulkCryptAlg 
Encrypted (Content) 
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DigestedData = DigestAlg Content DigestBytes 
EncryptedData = BulkCryptAlg Encrypted (Bytes) 
SignerInfo = CertID ... Encrypted(DigestBytes) 
RecipientInfo = CertID KeyCryptAlg Encrypted (DEK) 


Appendix: Internet Media Type message/s-http 
In addition to defining the S-HTTP/1.4 protocol, this document serves 


as the specification for the Internet media type "message/s-http". 
The following is to be registered with IANA. 


Media Type name: message 

Media subtype name: s-http 

Required parameters: none 

Optional parameters: version, msgtype 


version: The S-HTTP version number of the enclosed message 
(e.g. "1.4"). If not present, the version can be 
determined from the first line of the body. 


msgtype: The message type -- "request" or "response". 
If not present, the type can be determined from the 
first line of the body. 


Encoding considerations: only "7bit", "8bit", or "binary" 
are permitted. 


Security considerations: this is a security protocol. 
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